Course: iOS App Development
Topic: Working with AsyncSequence and Asynchronous Data Streams
Course Link: iOS App Development Training at JustAcademy
Demo Link: Register for a Course Demo
Website: JustAcademy Official Website
In modern iOS development, applications often receive information gradually rather than all at once. Examples include live notifications, streaming network responses, file data, sensor updates, chat messages, and continuous application events. Processing these values one at a time is often more efficient and responsive than waiting for an entire collection to become available.
Swift provides the AsyncSequence protocol to represent a sequence of values that can become available asynchronously. It is similar to the regular Sequence protocol, but obtaining the next element may require the program to suspend while waiting for that element.
Developers commonly iterate over an asynchronous sequence using for await or for try await. Swift also provides tools such as AsyncStream and AsyncThrowingStream for creating asynchronous streams and adapting callback-based APIs.
Official reference: Apple Developer Documentation — AsyncSequence.
An asynchronous data stream is a source of values that become available over time. Instead of receiving all the values in one operation, the consumer waits for each new value when it is ready.
For example, a live stock-price application may receive a new price every few seconds. A chat application may receive new messages whenever other users send them. A file-processing application may read lines as data becomes available.
| Example | Stream values | Typical application |
|---|---|---|
| Live notifications | Notification events | Messaging and reminders |
| Network streaming | Chunks or lines of response data | Live feeds and streamed content |
| Location updates | Location measurements | Navigation and fitness applications |
| Sensor updates | Motion or device readings | Health and activity tracking |
| File reading | Bytes or lines of text | Log processing and import tools |
| Application events | State-change notifications | Reactive user interfaces |
A regular sequence is generally iterated synchronously. An asynchronous sequence allows the consumer to wait for values without blocking the current thread while those values are unavailable.
| Feature | Sequence | AsyncSequence |
|---|---|---|
| Element retrieval | Synchronous | Asynchronous |
| Iteration syntax | for item in items |
for await item in items |
| Waiting for values | Does not use asynchronous iteration. | Can suspend while waiting for the next value. |
| Typical source | Arrays, ranges, collections | Events, streams, asynchronous data sources |
| Error propagation | Depends on the operation used. | Throwing streams can propagate errors during iteration. |
| Use case | Processing values already available | Processing values that arrive over time |
let numbers = [10, 20, 30, 40]
for number in numbers {
print(number)
}All four values are already available in the array, so a normal loop is sufficient.
func processNumbers() async {
for await number in Counter(howHigh: 5) {
print(number)
}
}This example assumes a custom asynchronous sequence named Counter that produces numbers. The loop waits asynchronously for each next value.
AsyncSequence is a Swift protocol that defines how asynchronous values can be iterated. A conforming type provides an element type and an asynchronous iterator.
The for await loop is the most common way to consume an AsyncSequence. It makes asynchronous iteration look similar to ordinary loop syntax.
func printMessages() async {
let messages = ["Welcome", "Hello", "Goodbye"]
for await message in messages.async {
print(message)
}
}The example uses an asynchronous adapter for a regular sequence. Availability of the .async convenience depends on the Swift APIs and libraries used by the project. When an array does not provide the required adapter in your target, use an explicit AsyncStream or another supported asynchronous sequence.
AsyncStream makes it possible to create an asynchronous sequence by yielding values through a continuation. It is especially useful when adapting callback-based APIs, delegates, or event handlers to Swift concurrency.
import Foundation
func createMessageStream() -> AsyncStream<String> {
AsyncStream { continuation in
continuation.yield("Application started")
continuation.yield("Loading data")
continuation.yield("Data loaded")
continuation.finish()
}
}
func consumeMessages() async {
for await message in createMessageStream() {
print(message)
}
}In this example, the continuation produces three messages and then finishes the stream. The consumer receives each value through the asynchronous loop.
| Method | Purpose |
|---|---|
yield(_:) |
Offers a value to the stream's consumer. |
finish() |
Marks the stream as complete. |
onTermination |
Allows cleanup when the stream terminates or the consumer is cancelled. |
Calling finish() is important when a stream has no more values to produce. For a long-running event source, finish the stream when the source is stopped or its lifetime ends.
AsyncThrowingStream is similar to AsyncStream but supports reporting an error to the consumer. It is useful when a data source can finish normally or fail during processing.
import Foundation
enum StreamError: Error {
case sourceFailed
}
func createThrowingStream() -> AsyncThrowingStream<Int, Error> {
AsyncThrowingStream { continuation in
continuation.yield(1)
continuation.yield(2)
continuation.finish(throwing: StreamError.sourceFailed)
}
}
func consumeThrowingStream() async {
do {
for try await value in createThrowingStream() {
print(value)
}
} catch {
print("Stream failed: \(error)")
}
}The consumer receives values that were yielded before the error and then handles the failure through a do-catch block. This is useful for event sources that can encounter a real error while operating.
| Feature | AsyncStream | AsyncThrowingStream |
|---|---|---|
| Values over time | Supported | Supported |
| Normal completion | Supported | Supported |
| Propagating a stream error | Not through a throwing iteration interface | Supported |
| Iteration | for await |
for try await |
| Suitable examples | Simple event notifications | File processing or event sources that can fail |
AsyncSequence provides operations that can transform, filter, and summarize values. These operations help keep stream-processing code readable.
The map operation transforms each element into a new value.
func transformNumbers() async {
let numbers = Counter(howHigh: 5)
let labels = numbers.map { number in
"Number: \(number)"
}
for await label in labels {
print(label)
}
}This example assumes the custom Counter sequence produces integer values. The transformed sequence produces strings.
The filter operation keeps values that satisfy a condition.
func printEvenNumbers() async {
let numbers = Counter(howHigh: 10)
let evenNumbers = numbers.filter { number in
number % 2 == 0
}
for await number in evenNumbers {
print(number)
}
}prefix limits the sequence to an initial number of elements, while dropFirst skips a specified number of elements.
func readLimitedStream() async {
let numbers = Counter(howHigh: 10)
for await number in numbers.prefix(3) {
print(number)
}
}This example processes only the first three values supplied by the sequence. The exact sequence behavior depends on the implementation of Counter.
The reduce operation combines the elements into a single result.
func calculateTotal() async {
let numbers = Counter(howHigh: 5)
let total = await numbers.reduce(0) { partial, number in
partial + number
}
print("Total: \(total)")
}Use reducing operations carefully on unbounded streams. A stream that never ends may never produce a final reduction result.
In advanced Swift applications, a developer can implement AsyncSequence to provide a custom asynchronous iterator. This is useful when an existing data source does not already provide a compatible asynchronous sequence.
The following conceptual example shows a counter that yields values up to a specified limit. It uses an asynchronous iterator and is intended to demonstrate the protocol structure.
struct Counter: AsyncSequence {
typealias Element = Int
let howHigh: Int
struct AsyncIterator: AsyncIteratorProtocol {
var current = 1
let limit: Int
mutating func next() async -> Int? {
guard current <= limit else {
return nil
}
let result = current
current += 1
return result
}
}
func makeAsyncIterator() -> AsyncIterator {
AsyncIterator(limit: howHigh)
}
}The iterator's next() method returns an optional element. A returned value continues iteration, while nil signals that the sequence has ended. This particular counter does not need to wait for external data, but the asynchronous protocol allows other implementations to suspend while obtaining values.
Many older iOS APIs use callbacks or delegate methods. AsyncStream can bridge these APIs to a consumer that uses modern asynchronous iteration.
import Foundation
func eventStream(
start: (@escaping (String) -> Void) -> Void
) -> AsyncStream<String> {
AsyncStream { continuation in
start { event in
continuation.yield(event)
}
}
}This simple example demonstrates how callback values can be yielded into an asynchronous stream. A production adapter should also define how the source stops, how the continuation finishes, and how cleanup occurs when the consumer cancels its task.
Applications often respond to system or application notifications. Foundation notification APIs can expose notifications through an asynchronous sequence on supported Apple platform versions.
import Foundation
func observeApplicationEvents() async {
let notifications = NotificationCenter.default.notifications(
named: UIApplication.willEnterForegroundNotification
)
for await notification in notifications {
print("Application is entering the foreground")
print(notification.name)
}
}This example uses UIApplication, so import UIKit in an iOS target. The observation function should run in a task whose lifetime matches the desired observation period. If the task is cancelled, the loop stops observing through that consumer.
Some network responses are delivered incrementally rather than as one complete JSON document. Examples include server-sent events, line-based feeds, large files, and streamed text responses.
When using URLSession, choose the API that matches the response format. A standard data request is appropriate for many JSON APIs, while byte-oriented or download APIs may be better for large or incrementally processed resources.
import Foundation
func readResponseLines(from url: URL) async throws {
let (bytes, response) = try await URLSession.shared.bytes(from: url)
guard let httpResponse = response as? HTTPURLResponse,
(200...299).contains(httpResponse.statusCode) else {
throw URLError(.badServerResponse)
}
for try await line in bytes.lines {
print(line)
}
}The example reads a response as lines. It is most suitable when the endpoint returns a line-oriented format. A regular JSON API usually returns a complete JSON document, so decoding the collected response data may be more appropriate in that case.
Important: Receiving response bytes as a stream does not automatically mean that the server is sending application-level events. Confirm the endpoint's response format and content type before processing the stream.
Asynchronous streams may run for a long time. Examples include live updates, notifications, sensor monitoring, and persistent event feeds. Cancellation helps prevent unnecessary work when a screen is dismissed or the user stops monitoring the data.
let streamTask = Task {
for await value in createMessageStream() {
if Task.isCancelled {
break
}
print(value)
}
}
// When the work is no longer required:
streamTask.cancel()Cancellation is cooperative. A task or its underlying data source must respond appropriately to cancellation. For custom streams, use the continuation's termination handler to clean up external resources and stop event production when appropriate.
func createManagedStream() -> AsyncStream<String> {
AsyncStream { continuation in
continuation.onTermination = { termination in
print("Stream terminated: \(termination)")
// Remove observers or stop the external event source here.
}
continuation.yield("Ready")
}
}This example shows where cleanup logic belongs. In a complete implementation, the source must also define when it finishes and how its lifetime is coordinated with the stream consumer.
A producer can sometimes generate values faster than a consumer can process them. For example, a sensor may emit many measurements while the UI can display only occasional updates. Buffering policy determines what happens to values waiting to be consumed.
| Strategy | Behavior | Example use case |
|---|---|---|
| Unbounded buffering | Retains pending values without a fixed buffer limit. | Only when growth is controlled and memory use is acceptable. |
| Buffering newest | Prioritizes keeping the most recent values within the configured buffer capacity. | Live sensor readings or current status indicators. |
| Buffering oldest | Preserves older pending values within the configured buffer capacity. | Situations where earlier queued values are more important. |
| Source-level throttling | Reduces the rate at which the source produces values. | Expensive event processing or UI updates. |
AsyncStream supports buffering policies such as unbounded buffering and bounded buffering that keeps the newest or oldest pending elements. Select the policy based on whether the application needs every event or mainly needs the latest state.
SwiftUI applications can consume asynchronous sequences inside a task associated with a view. This is useful for updating a screen when new events arrive.
import SwiftUI
struct MessageStreamView: View {
@State private var messages: [String] = []
var body: some View {
List(messages, id: \.self) { message in
Text(message)
}
.task {
for await message in createMessageStream() {
messages.append(message)
}
}
}
}This example assumes that createMessageStream() produces a finite sequence of messages. For a long-running stream, consider limiting stored messages and ensuring that the stream terminates or cleans up when the view no longer needs it.
.task for asynchronous work tied to a view's lifecycle.Not all asynchronous sequences can fail in the same way. A nonthrowing AsyncStream does not expose errors through a throwing iteration loop. An AsyncThrowingStream can propagate an error, while other asynchronous sequences may have their own failure behavior.
func monitorStream() async {
do {
for try await value in createThrowingStream() {
print("Received: \(value)")
}
print("Stream completed")
} catch {
print("Unable to continue stream: \(error)")
}
}The example assumes that createThrowingStream() returns an AsyncThrowingStream. In a real application, distinguish expected cancellation from actual source failures and provide appropriate recovery behavior.
| Mistake | Why it matters | Recommended solution |
|---|---|---|
| Using a normal for loop on an asynchronous sequence | The sequence requires asynchronous iteration. | Use for await or for try await. |
| Forgetting to finish a finite stream | The consumer may continue waiting for values. | Call finish() when production is complete. |
| Ignoring stream errors | Failures can terminate processing unexpectedly. | Use a throwing stream and handle errors with do-catch when appropriate. |
| Failing to remove observers | Resources or event sources may remain active unnecessarily. | Use lifecycle-aware cleanup and termination handlers. |
| Buffering unlimited events | Memory usage can grow excessively. | Choose a suitable buffering policy or reduce event production. |
| Assuming cancellation automatically stops external work | Callbacks or sources may continue producing values. | Connect cancellation to explicit source cleanup. |
| Updating UI state from an unsuitable context | Can cause concurrency warnings or inconsistent state. | Use main-actor isolation for UI-facing state. |
| Using line-based reading for ordinary JSON | The response may not be organized as individual lines. | Use the decoding approach that matches the API response format. |
Create a simple iOS application that displays messages as they arrive through an asynchronous stream. This project demonstrates stream creation, iteration, SwiftUI state updates, and lifecycle management.
Answer: AsyncSequence is a protocol that represents values that can be accessed sequentially and asynchronously, one element at a time.
Answer: Sequence provides synchronous iteration, while AsyncSequence allows retrieving the next value to suspend while waiting for it.
Answer: It iterates over an asynchronous sequence and waits asynchronously for each next element.
Answer: AsyncStream is a standard-library type that creates an asynchronous sequence by allowing a producer to yield values through a continuation.
Answer: AsyncThrowingStream supports asynchronous values and can finish by reporting an error to the consumer.
Answer: It offers a value to the asynchronous stream for consumption.
Answer: It signals that the stream has ended and no more values will be produced.
Answer: An AsyncStream can bridge callback events into an asynchronous sequence by yielding values through a continuation.
Answer: The consumer task should respect cancellation, and the producer should stop unnecessary work and release resources when the stream terminates.
Answer: Buffering controls how pending values are retained when the producer emits values faster than the consumer processes them.
Answer: Yes. A SwiftUI view can consume an asynchronous sequence in a task and update appropriately isolated UI state as values arrive.
Answer: It is useful for events, notifications, streamed data, file lines, and other situations where values become available over time.
AsyncSequence and asynchronous data streams are important tools for building modern iOS applications that work with values arriving over time. They provide a structured way to consume events, notifications, network data, and other asynchronous sources using familiar Swift iteration syntax.
By understanding AsyncSequence, AsyncStream, AsyncThrowingStream, buffering, error handling, and cancellation, developers can write more maintainable and responsive asynchronous code. Applying these techniques in SwiftUI applications helps manage continuous data updates while keeping resource usage and application lifecycle behavior under control.
